Update miden-node to Plonky3 (and new miden-crypto, miden-vm, miden-base)#1482
Update miden-node to Plonky3 (and new miden-crypto, miden-vm, miden-base)#1482huitseeker wants to merge 3 commits intonextfrom
Conversation
Update project dependencies to use Plonky3-based miden versions: - miden-crypto v0.20 - miden-vm from github.com/0xMiden/miden-vm (branch al-migrate-p3-ver2) - miden-base from github.com/0xMiden/miden-base (branch huitseeker/update-miden-deps-p3) - Add miden-core git dependency Fix breaking API changes: - Replace StarkField::MODULUS with PrimeField64::ORDER_U64 - Remove FieldElement imports (no longer exported) - Change Felt::ZERO/ONE to ZERO/ONE constants - Update MMR proof field access to use methods (.forest(), .merkle_path()) - Add missing LargeSmtError enum variants (RootMismatch, StorageNotEmpty) - Replace ExecutionProof::new_dummy() with struct construction - Handle HashFunction type conflicts from aliased git repos using transmute
…ntime detection The miden-vm prover's prove_sync() method detects when it's called from within a Tokio runtime and panics, recommending to use the async prove() method instead. Even tokio::task::spawn_blocking() still runs within the Tokio runtime context and triggers this check. Changes: - Wrap Prover enum's Mutex types in Arc to allow cloning - Use std::thread::spawn() instead of spawn_blocking() for prove_tx - Use tokio::sync::oneshot channel to communicate result back to async context - This allows the sync prove() call to run outside Tokio's runtime detection The prove_batch and prove_block methods remain unchanged as they are synchronous and not called from async context in the same way. Fixes the test_prove_transaction test failure.
- Change try_from to from for infallible u64 to Felt conversions - Add clippy::missing_transmute_annotations allow for HashFunction transmutes - Remove unused miden-air dependency from stress-test crate - Remove let-and-return pattern in test utilities These are cleanup items from the new miden dependencies that have stricter type conversions and new clippy lints.
cc92a33 to
e24d83d
Compare
|
I've rebased, stress-test is failing though - @SantiagoPittella could you see if you could resolve it? Or if its a bug/issue in the protocol branch. |
|
Sure, I'm taking a look. |
|
I think the error comes from some changes in if self.smt.get_leaf(&id_key).is_ok() {
return Err(DuplicateIdPrefix);
}With the old impl we were checking if I think this probably will arise too when using the network monitor, but currently has this error at start up: |
|
Ah, I can help there. The tokio failure you're seeing is discussed in 0xMiden/miden-vm#2501, and the issue is you're trying to call a sync API that starts a runtime from another runtime. The processor's main API has changed to be async (PoC: @plafer) and these |
This prefigures the upcoming miden-base, miden-vm & miden-crypto versions. Working branch made to work out the kinks of :